揭秘 .wasm 文件：WebAssembly 自定义段指南

WebAssembly (Wasm) 从根本上改变了我们对 Web 及其他领域高性能代码的看法。它通常被誉为一种适用于 C++、Rust 和 Go 等语言的可移植、高效且安全的编译目标。但一个 Wasm 模块不仅仅是一系列低级指令。WebAssembly 二进制格式是一种复杂的结构，其设计不仅是为了执行，也是为了可扩展性。这种可扩展性主要通过一个强大但常被忽视的功能来实现：自定义段 (custom sections)。

如果你曾在浏览器的开发者工具中调试过 C++ 代码，或者好奇一个 Wasm 文件如何知道它是由哪个编译器创建的，那么你已经接触到了自定义段的作用。它们是元数据、调试信息和其他非必要数据的指定存放位置，这些数据丰富了开发者体验，并为整个工具链生态系统赋能。本文将全面深入地探讨 WebAssembly 自定义段，探索它们是什么、为何至关重要，以及你如何在自己的项目中利用它们。

WebAssembly 模块剖析

在理解自定义段之前，我们必须首先了解 .wasm 二进制文件的基本结构。一个 Wasm 模块由一系列定义明确的“段”组成。每个段都有特定的用途，并由一个数字 ID 标识。

WebAssembly 规范定义了一组标准的或“已知的”段，Wasm 引擎需要这些段来执行代码。这些段包括：

• 类型 (ID 1): 定义模块中使用的函数签名（参数和返回类型）。
• 导入 (ID 2): 声明模块从其宿主环境（例如 JavaScript 函数）导入的函数、内存或表。
• 函数 (ID 3): 将模块中的每个函数与类型段中的一个签名关联起来。
• 表 (ID 4): 定义表，主要用于实现间接函数调用。
• 内存 (ID 5): 定义模块使用的线性内存。
• 全局 (ID 6): 为模块声明全局变量。
• 导出 (ID 7): 使模块中的函数、内存、表或全局变量可供宿主环境使用。
• 起始 (ID 8): 指定一个在模块实例化时自动执行的函数。
• 元素 (ID 9): 使用函数引用初始化一个表。
• 代码 (ID 10): 包含模块中每个函数的实际可执行字节码。
• 数据 (ID 11): 初始化线性内存的段，常用于静态数据和字符串。

这些标准段是任何 Wasm 模块的核心。Wasm 引擎会严格解析它们以理解和执行程序。但如果工具链或语言需要存储执行时不需要的额外信息怎么办？这就是自定义段发挥作用的地方。

究竟什么是自定义段？

自定义段是 Wasm 模块中用于存储任意数据的通用容器。规范将其定义为一个特殊的段 ID 0。其结构简单但功能强大：

1. 段 ID: 始终为 0，表示它是一个自定义段。
2. 段大小: 后面内容的总大小（以字节为单位）。
3. 名称: 一个 UTF-8 编码的字符串，用于标识自定义段的用途（例如，“name”、“.debug_info”）。
4. 有效载荷: 包含该段实际数据的一系列字节。

关于自定义段最重要的规则是：不识别某个自定义段名称的 WebAssembly 引擎必须忽略其有效载荷。 它会简单地跳过由段大小定义的字节。这优雅的设计带来了几个关键好处：

• 前向兼容性：新工具可以引入新的自定义段，而不会破坏旧的 Wasm 运行时。
• 生态系统可扩展性：语言实现者、工具开发者和打包工具可以嵌入自己的元数据，而无需更改核心 Wasm 规范。
• 解耦：执行逻辑与元数据完全解耦。自定义段的存在与否对程序的运行时行为没有影响。

可以把自定义段看作 JPEG 图像中的 EXIF 数据或 MP3 文件中的 ID3 标签。它们提供了有价值的上下文，但对于显示图像或播放音乐来说并非必需。

常见用例 1：“name” 段用于人类可读的调试

最广泛使用的自定义段之一是 name 段。默认情况下，Wasm 函数、变量和其他项目都通过其数字索引来引用。当查看原始的 Wasm 反汇编代码时，你可能会看到像 call $func42 这样的内容。虽然这对于机器来说很高效，但对人类开发者来说没什么帮助。

name 段通过提供一个从索引到人类可读字符串名称的映射来解决这个问题。这使得反汇编器和调试器等工具能够显示来自原始源代码的有意义的标识符。

例如，如果你编译一个 C 函数：

            int calculate_total(int items, int price) {
    return items * price;
}
            

              
                Copy
              
            
          

编译器可以生成一个 name 段，将内部函数索引（例如 42）与字符串“calculate_total”关联起来。它还可以命名局部变量“items”和“price”。当你在支持此段的工具中检查 Wasm 模块时，你会看到更具信息量的输出，这有助于调试和分析。

name 段的结构

name 段本身又被划分为多个子段，每个子段由单个字节标识：

• 模块名称 (ID 0): 为整个模块提供一个名称。
• 函数名称 (ID 1): 将函数索引映射到它们的名称。
• 局部变量名称 (ID 2): 将每个函数内的局部变量索引映射到它们的名称。
• 标签名称、类型名称、表名称等: 还存在其他子段，用于命名 Wasm 模块中几乎所有的实体。

name 段是实现良好开发者体验的第一步，但这仅仅是个开始。要实现真正的源码级调试，我们需要更强大的东西。

调试的利器：自定义段中的 DWARF

Wasm 开发的终极目标是源码级调试：能够直接在浏览器的开发者工具中设置断点、检查变量，并单步调试你的原始 C++、Rust 或 Go 代码。这种神奇的体验几乎完全是通过将 DWARF 调试信息嵌入到一系列自定义段中来实现的。

什么是 DWARF？

DWARF (Debugging With Attributed Record Formats) 是一种标准化的、与语言无关的调试数据格式。它与 GCC 和 Clang 等原生编译器使用的格式相同，用于支持 GDB 和 LLDB 等调试器。它的内容极其丰富，可以编码大量信息，包括：

• 源码映射：从每条 WebAssembly 指令到原始源文件、行号和列号的精确映射。
• 变量信息：局部和全局变量的名称、类型和作用域。它知道在代码的任何给定点，变量存储在哪里（在寄存器中、在栈上等）。
• 类型定义：对源语言中复杂类型（如结构体、类、枚举和联合）的完整描述。
• 函数信息：关于函数签名的详细信息，包括参数名称和类型。
• 内联函数映射：即使函数被优化器内联，也能重建调用栈的信息。

DWARF 如何与 WebAssembly 协同工作

像 Emscripten (使用 Clang/LLVM) 和 `rustc` 这样的编译器有一个标志（通常是 -g 或 -g4），指示它们在生成 Wasm 字节码的同时生成 DWARF 信息。然后，工具链会获取这些 DWARF 数据，将其分割成逻辑部分，并将每个部分嵌入到 .wasm 文件中的一个单独的自定义段中。按照惯例，这些段的名称以点开头：

• .debug_info: 包含主要调试条目的核心段。
• .debug_abbrev: 包含缩写，以减小 .debug_info 的大小。
• .debug_line: 用于将 Wasm 代码映射到源代码的行号表。
• .debug_str: 其他 DWARF 段使用的字符串表。
• .debug_ranges, .debug_loc, 以及许多其他段。

当你在像 Chrome 或 Firefox 这样的现代浏览器中加载这个 Wasm 模块并打开开发者工具时，工具内的 DWARF 解析器会读取这些自定义段。它会重建所有需要的信息，向你展示原始源代码的视图，让你能够像调试原生运行的代码一样进行调试。

这是一个颠覆性的改变。如果没有自定义段中的 DWARF，调试 Wasm 将是一个痛苦的过程，需要盯着原始内存和难以理解的反汇编代码。有了它，开发循环变得像调试 JavaScript 一样无缝。

超越调试：自定义段的其他用途

虽然调试是一个主要用例，但自定义段的灵活性使其被广泛用于各种工具和特定语言的需求。

工具特定元数据：`producers` 段

了解一个给定的 Wasm 模块是使用什么工具创建的通常很有用。`producers` 段就是为此设计的。它存储了关于工具链的信息，例如编译器、链接器及其版本。例如，一个 `producers` 段可能包含：

• 语言: "C++ 17", "Rust 1.65.0"
• 处理工具: "Clang 16.0.0", "binaryen 111"
• SDK: "Emscripten 3.1.25"

这些元数据对于复现构建、向正确的工具链作者报告错误，以及需要了解 Wasm 二进制文件来源的自动化系统来说，是无价的。

链接与动态库

WebAssembly 规范的最初形式没有链接的概念。为了能够创建静态和动态库，人们使用自定义段建立了一个约定。`linking` 自定义段包含了 Wasm 感知链接器（如 `wasm-ld`）解析符号、处理重定位和管理共享库依赖所需的元数据。这使得大型应用程序可以被分解成更小、更易于管理的模块，就像在原生开发中一样。

特定语言的运行时

具有托管运行时的语言，如 Go、Swift 或 Kotlin，通常需要一些不属于核心 Wasm模型的元数据。例如，垃圾收集器（GC）需要知道内存中数据结构的布局以识别指针。这些布局信息可以存储在自定义段中。同样，Go 中的反射等功能可能依赖自定义段在编译时存储类型名称和元数据，然后 Wasm 模块中的 Go 运行时可以在执行期间读取这些数据。

未来：WebAssembly 组件模型

WebAssembly 最激动人心的未来方向之一是组件模型 (Component Model)。该提案旨在实现 Wasm 模块之间真正的、与语言无关的互操作性。想象一下，一个 Rust 组件无缝调用一个 Python 组件，后者又使用一个 C++ 组件，所有组件之间都传递着丰富的数据类型。

组件模型严重依赖自定义段来定义高级接口、类型和“世界”（worlds）。这些元数据描述了组件如何通信，使得工具能够自动生成必要的粘合代码。这是一个绝佳的例子，说明了自定义段如何为在核心 Wasm 标准之上构建复杂的新功能提供基础。

实践指南：检查与操作自定义段

理解自定义段很棒，但你如何使用它们呢？有几种标准工具可用于此目的。

必备工具

• WABT (The WebAssembly Binary Toolkit): 这个工具套件对于任何 Wasm 开发者都是必不可少的。其中的 wasm-objdump 工具特别有用。运行 wasm-objdump -h your_module.wasm 将列出模块中的所有段，包括自定义段。
• Binaryen: 这是一个强大的 Wasm 编译器和工具链基础设施。它包括 wasm-strip，一个用于从模块中移除自定义段的工具。
• Dwarfdump: 一个标准工具（通常与 Clang/LLVM 打包），用于以人类可读的格式解析和打印 DWARF 调试段的内容。

示例工作流：构建、检查、剥离

让我们用一个简单的 C++ 文件 main.cpp 来走一个常见的开发工作流：

            #include 

int main() {
    std::cout << "Hello from WebAssembly!" << std::endl;
    return 0;
}
            

              
                Copy
              
            
          

1. 编译并包含调试信息： 我们使用 Emscripten 将其编译为 Wasm，使用 -g 标志来包含 DWARF 调试信息。

emcc main.cpp -g -o main.wasm

2. 检查段信息： 现在，让我们使用 wasm-objdump 来看看里面有什么。

wasm-objdump -h main.wasm

输出将显示标准段（类型、函数、代码等）以及一长串自定义段，如 name、.debug_info、.debug_line 等等。注意文件大小；它会比非调试版本的构建大得多。

3. 为生产环境剥离： 对于生产发布，我们不希望交付这个包含所有调试信息的大文件。我们使用 wasm-strip 来移除它。

wasm-strip main.wasm -o main.stripped.wasm

4. 再次检查： 如果你运行 wasm-objdump -h main.stripped.wasm，你会看到所有的自定义段都消失了。main.stripped.wasm 的文件大小将只是原始文件的一小部分，使其下载和加载速度快得多。

权衡：大小、性能与可用性

自定义段，特别是用于 DWARF 的段，带来了一个主要的权衡：文件大小。DWARF 数据的大小是实际 Wasm 代码的 5-10 倍的情况并不少见。这可能对 Web 应用程序产生重大影响，因为下载时间至关重要。

这就是为什么“为生产环境剥离”的工作流程如此重要。最佳实践是：

• 开发期间：使用包含完整 DWARF 信息的构建版本，以获得丰富的源码级调试体验。
• 生产环境：向用户交付一个完全剥离的 Wasm 二进制文件，以确保尽可能小的体积和最快的加载时间。

一些高级设置甚至将调试版本托管在单独的服务器上。可以配置浏览器开发者工具，在开发者想要调试生产问题时按需获取这个更大的文件，从而两全其美。这与 JavaScript 的 source maps 工作方式类似。

需要注意的是，自定义段对运行时性能几乎没有影响。Wasm 引擎通过其 ID 0 快速识别它们，并在解析期间简单地跳过其有效载荷。一旦模块加载完毕，引擎就不会使用自定义段数据，因此它不会减慢代码的执行速度。

结论

WebAssembly 自定义段是可扩展二进制格式设计的典范。它们提供了一种标准化的、前向兼容的机制，用于嵌入丰富的元数据，而不会使核心规范复杂化或影响运行时性能。它们是驱动现代 Wasm 开发者体验的无形引擎，将调试从一门神秘的艺术转变为一个无缝、高效的过程。

从简单的函数名到 DWARF 的广阔天地，再到组件模型的未来，正是自定义段将 WebAssembly 从一个单纯的编译目标提升为一个繁荣的、工具完备的生态系统。下次当你在浏览器中运行的 Rust 代码中设置断点时，请花点时间感谢那些使其成为可能的、默默工作的强大自定义段。